home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000027_icon-group-sender _Mon Jan 18 13:52:51 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
2KB
Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 07:55:00 MST
Date: Mon, 18 Jan 1993 13:52:51 +0100
From: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber)
Message-Id: <9301181252.AA17972@soir.informatik.uni-tuebingen.de>
To: icon-group@cs.arizona.edu
In-Reply-To: (Michael Glass)'s message of Fri, 15 Jan 93 05:23:00 +0100
<14JAN199323230672@adcalc.fnal.gov*MAILER@cdc2-gw.rrzn.uni-hannover.de>
Subject: Pattern matching in Icon?
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
Well, at least one person got it (partially) right. I had't
thought of Prolog as the inspiration for the control structure
I had proposes, but in fact, a unification is what would happen
in pattern matching, albeit in a much more limited sense, that
is also easier and more straightforward to implement.
As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda,
ML or the like?!), the proposed scheme could be used to
implement structural recursion VERY elegantly - with the
added power of generators.
Steve Wampler proposed ...
>I guess the only real debate is whether to add it into the language
>or not:
>
> case s := <expression> of {
> match_syntax_tree(s,"let") : {a := s.arguments
> ...
> }
>
> ...
>
> procedure match_syntax_tree(s, op)
># match a pattern, in this case, the pattern is simple...
> if type(s) == "syntax_tree" & s.operator == "let" then
> return s
> end
>
>or, though I find this less readable:
>
> case s := <expression> of {
> 1(match_syntax_tree(s,"let"), a := s.arguments) : {...
> ...
>
>not as visually pleasing as a new syntax would be, but I contend
>this would be more flexible and generalizes better than fixed
>patterns would...
This stuff looks extremely awkward to me, in fact even more awkward
than doing the pattern matching explicitly. It would mean having
separate procedures (with different names, too!) for each constructor
AND combination of constants/unknowns. My proposal was exactly
aimed at removing that syntactic clumsiness. As I said (again,
and again), that's exactly why compilers are so much easier to
write and read in functional languages. The way to go would
probably be using the variant translator feature of Icon to do
the job. Anyone interested? (If I'm not all alone with this, I
might actually get around to doing it, some day ...)
Cheers :-> Chipsy